System which provides plural processes in a host with asynchronous access to plural portions of the memory of another host

ABSTRACT

API in conjunction with a bridge chip and first and second hosts having first and second memories respectively. The bridge chip connects the memories. The API comprises key identifier registration functionality to register a key identifier for each of plural computer processes performed by the first host, thereby to define plural key identifiers; and/or access control functionality to provide at least computer process P 1  performed by the first host with access, typically via the bridge chip, to at least local memory buffer M 2  residing in the second memory, typically after the access control functionality first validates that process P 1  has a key identifier which has been registered, e.g., via the key identifier registration functionality. Typically, the access control functionality also prevents at least computer process P 2 , performed by the first host, which has not registered a key identifier, from accessing local memory buffer M 2 , e.g., via the bridge chip.

FIELD

This invention relates generally to bridge chips, and more specificallyto Non-Transparent Bridges (NTBs).

BACKGROUND

Transparent bridging is described in the following online link:etutorials.org/Networking/Lan+switching+fundamentals/Chapter+1.+LAN+Switching+Foundation+Technologies/Transparent+Bridging/.

Missinglinkelectronics.com explains (in this link:missinglinkelectronics.com/devzone/index.php/fpga-debug-ntb), using RCto stand for “root complex”, that:

“NTB stands for Non-Transparent Bridge. Unlike in a PCI-Express aka PCIe(transparent) Bridge where the RC “sees” all the PCIe busses all the wayto all the Endpoints, an NTB forwards the PCIe traffic between theseparate PCIe busses like a bridge. Each RC sees the NTB as an Endpointdevice but does not see the other RC and devices on the other side.Means, everything behind the NTB is not directly visible to theparticular RC, thus “Non-Transparent”.”

Eetimes.com describes (in the following online link:eetimes.com/non-transparent-bridging-makes-pci-express-ha-friendly/#)that “A non-transparent bridge is functionally similar to a transparentbridge, with the exception that there is an intelligent device orprocessor on both sides of the bridge, each with its own independentaddress domain. The host on one side of the bridge will not have thevisibility of the complete memory or I/O space on the other side of thebridge.”

“Mellanox Multi-Host technology enables connecting a number ofcompute/storage hosts to a single ConnectX® network adapter” e.g., asdescribed in this online link:docs.mellanox.com/display/BlueFieldSWv31011424/Multi-host.

Broadband.com describes (in the following online publication:docs.broadcom.com/doc/12353427) that “Developers have been usingnon-transparent bridging . . . for years to design multi-host systemsand intelligent I/Os . . . . The non-transparent bridging (NTB) functionenables isolation of two hosts or memory domains yet allows status anddata exchange between the two hosts or sub-systems.”

An example of non-transparent bridges (NTBs) being used to share memorybetween 2 hosts is provided in the following online publication:kernel.org/doc/html/latest/driver-api/ntb.html and includes thefollowing operations:

“Local Device:

-   -   1. Allocate memory for a shared window    -   2. Initialize memory window by translated address of the        allocated region (it may fail if local memory window        initialization is unsupported)    -   3. Send the translated address and memory window index to a peer        device        Peer Device:    -   1. Initialize memory window with retrieved address of the        allocated by another device memory region (it may fail if peer        memory window initialization is unsupported)    -   2. Map outbound memory window”.

The online publication at the following link:docs.broadcom.com/doc/12353428#:˜:text=A%20transparent%20bridge%20does%20not,opposite%20(other%20side)%20interfaceprovides a detailed technical comparison between transparent andnon-transparent bridges. It is appreciated that non-transparent bridgesneed not have each and every technical feature referred to in thispublication.

Asynchronous I/O is described in the following online publication:en.wikipedia.org/wiki/Asynchronous_I/O.

SUMMARY OF THE DISCLOSURE

Certain embodiments seek to provide an asynchronous and/ornon-privileged NTB control and an input-output Application ProgrammingInterface (IO API). Typically, the IO API provides IO (input-output)between hosts which may be interconnected by an NTB and also providesNTB control of a-synchronous read and write transactions between thehosts, or of the IO. Typically, a given process (which may be running onone of the hosts) need not arrest its processing until the transactionhas been completed; instead, typically, the process may continue itsprocessing even though the transaction has not yet completed.

Certain embodiments seek to provide non-privileged Non-TransparentBridge control and/or non-privileged Non-Transparent Bridge IO, which istypically non-privileged in the sense that the control and/or IO may beperformed by a (typically any) non-privileged process rather than onlyby processes which are privileged.

At least the following embodiments are provided:

Embodiment 1. API (application programming interface) apparatusoperative in conjunction with a bridge chip, a first host and a secondhost, wherein the first and second hosts have first and second memoriesrespectively, and wherein the bridge chip connects the first and secondmemories, the apparatus comprising: key identifier registrationfunctionality to register a key identifier for each of plural computerprocesses performed by the first host, thereby to define plural keyidentifiers; and/or access control functionality to provide at least onecomputer process P1 performed by the first host with access, typicallyvia the bridge chip, to at least one local memory buffer M2 residing inthe second memory, typically after the access control functionalityfirst validates that the computer process P1 has a key identifier whichhas been registered, e.g., via the key identifier registrationfunctionality, and wherein, typically, the access control functionalityalso prevents at least one computer process P2, which is performed bythe first host and/or which has not registered a key identifier via thekey identifier registration functionality, from accessing the localmemory buffer M2, e.g., via the bridge chip.

Embodiment 2. Apparatus according to any of the embodiments describedherein wherein the first host, which has a local memory buffer M1,registers the local memory buffer in the bridge chip and, responsively,receives a key identifier from the bridge chip.

Embodiment 3. Apparatus according to any of the embodiments describedherein wherein the second host registers the local memory buffer M2 inthe bridge chip and, responsively, receives a key identifier from thebridge chip.

Embodiment 4. Apparatus according to any of the embodiments describedherein wherein at least one command to perform a read transaction isissued by the first host and wherein the command comprises a targetaddress and a local address where the bridge chip writes a read responsewhich is required at the target address.

Embodiment 5. Apparatus according to any of the embodiments describedherein wherein at least one command to perform a write transaction isissued by the first host and wherein the command comprises a targetaddress and a local address from which the bridge chip takes write data.

Embodiment 6. Apparatus according to any of the embodiments describedherein wherein the command also comprises a transaction size parameterindicative of an amount of data to be read.

Embodiment 7. Apparatus according to any of the embodiments describedherein wherein the command also comprises a transaction size parameterindicative of an amount of data to be written.

Embodiment 8. Apparatus according to any of the embodiments describedherein wherein the bridge chip receives the command via the API and,responsively, makes a validation attempt including attempting tovalidate that the command has a valid key from the first host (aka validlocal key) and a valid key from the second host (aka valid remote key)and wherein the read transaction is performed only after the bridge chipsucceeds in the validation attempt.

Embodiment 9. Apparatus according to any of the embodiments describedherein wherein the bridge chip receives the command via the API and,responsively, makes a validation attempt including attempting tovalidate that the command has a valid key from the first host (aka validlocal key) and a valid key from the second host (aka valid remote key)and wherein the write transaction is performed only after the bridgechip succeeds in the validation attempt.

Embodiment 10. Apparatus according to any of the embodiments describedherein and wherein, to indicate that the read transaction has beenperformed, a command counter is incremented.

Embodiment 11. Apparatus according to any of the embodiments describedherein and wherein, to indicate that the write transaction has beenperformed, a command counter is incremented.

Embodiment 12. Apparatus according to any of the embodiments describedherein and wherein the bridge chip comprises a Non-Transparent Bridge(NTB) which connects plural memories residing on plural computersrespectively, to a single PCI-Express fabric.

Embodiment 13. Apparatus according to any of the embodiments describedherein wherein the second host includes a smart NIC.

Embodiment 14. Apparatus according to any of the embodiments describedherein wherein the second host comprises a DPU.

Embodiment 15. Apparatus according to any of the embodiments describedherein and wherein an error message is generated each time the bridgechip determines that the first host does not have a key identifierregistered via the key identifier registration functionality.

Embodiment 16. Apparatus according to any of the embodiments describedherein which provides an interface to the bridge chip and providesmemory isolation between at least one computer process A performed by afirst host and the at least one local memory buffer M2.

Embodiment 17. Apparatus according to any of the embodiments describedherein and wherein the API apparatus also comprises:

-   -   an additional key identifier registration functionality and    -   an additional access control functionality, which provides at        least one computer process P3 performed by the second host with        access via the bridge chip to at least one local memory buffer        M1 residing in the first memory, after the additional access        control functionality first validates that the computer process        P3 has a key identifier which has been registered via the        additional key identifier registration functionality,    -   and wherein the additional access control functionality also        prevents at least one computer process P4, which is performed by        the second host and which has not registered a key identifier        via the additional key identifier registration functionality,        from accessing the local memory buffer M1 via the bridge chip.

Embodiment 18. Apparatus according to any of the embodiments describedherein wherein the API (Application Programming Interface) apparatusincludes the bridge chip, the first host, and the second host.

Embodiment 19. Apparatus according to any of the embodiments describedherein and wherein a completion bit is provided, to indicate that theread transaction has been performed.

Embodiment 20. Apparatus according to any of the embodiments describedherein and wherein a completion bit is provided, to indicate that thewrite transaction has been performed.

Embodiment 21. An application programming interfacing method operativein conjunction with a bridge chip, a first host and a second host,wherein the first and second hosts have first and second memoriesrespectively, and wherein the bridge chip connects the first and secondmemories, the method comprising:

-   -   registering a key identifier for each of plural computer        processes performed by the first host, thereby to define plural        key identifiers; and    -   providing at least one computer process P1 performed by the        first host with access via the bridge chip to at least one local        memory buffer M2 residing in the second memory, after first        validating that the computer process P1 has a key identifier        which has been registered, and    -   preventing at least one computer process P2, which is performed        by the first host and which has not registered a key identifier,        from accessing the local memory buffer M2 via the bridge chip.

Embodiment 22. Apparatus according to any of the embodiments describedherein wherein the key identifier identifies the local memory buffer M2.

Embodiment 23. Apparatus according to any of the embodiments describedherein wherein the key identifier uniquely identifies the local memorybuffer M2.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified block diagram of a system for non-privilegedNon-Transparent Bridge control and IO which is constructed and operativein accordance with an embodiment of the invention.

FIG. 2 is a simplified flowchart illustration of a method providingnon-privileged Non-Transparent Bridge control and IO, whereby pluralprocesses in a host, e.g., DPU host, may asynchronously access variousparts of a main host's memory, with various granularities, all inaccordance with an embodiment of the invention; all or any suitablesubset of the illustrated operations may be performed, eitherstand-alone or in conjunction with all or any suitable subset of theblocks shown in FIG. 1 . The method may be performed each time a firsthost issues a memory request to a second host's memory, via a bridgesuch as an NTB.

FIGS. 3 a-3 b are simplified block diagrams of multi-host environmentsin which embodiments herein may be implemented.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

Multi-host technology, which is known, allows multiple compute orstorage hosts to connect into a single interconnect adapter, for exampleby separating an adapter (PCIe, for example) bus into severalindependent interfaces. For example, Mellanox Multi-Host™ technology,first introduced with ConnectX®-4, is enabled in the Mellanox SocketDirect card. This technology allows plural hosts to be connected into asingle adapter by separating the PCIe (for example) interface intoplural independent interfaces. As described for example in the followinghttps www link: nvidia.com/en-us/networking/multi-host/, each interfacetypically connects to a separate host CPU. Typically, in multi-hostarchitectures, multiple hosts connect directly to a single networkcontroller, yielding direct access to data with low capital andoperating expenses. The multi-host architecture may include differentCPU architectures (e.g., x86 and/or Power and/or ARM central processingunits) where each host is independent of the others, yet all hosts mayshare the same network interface which conserves switch ports, cables,real estate and power.

A PCI (peripheral component interconnect) or PCIe device, whenaddressed, is typically enabled e.g., by being mapped into a system'sI/O port address space or memory-mapped address space. The system'sfirmware, device drivers, or the operating system may program so-called“Base Address” Registers (aka BARs) to inform the device of the PCIedevice's address mapping e.g., by writing configuration commands to thePCIe controller.

InfiniBand (IB) is a computer networking communications standard, usedfor data interconnect among and/or within computers e.g., supercomputersand/or as a direct or switched interconnect either between servers andstorage systems, or among storage systems.

Published InfiniBand specifications are available from the InfiniBandtrade association. InfiniBand provides remote direct memory access(RDMA) capabilities for low CPU overhead. InfiniBand uses a switchedfabric network topology aka switching fabric in which, typically, nodesinterconnect via more network switches, such as crossbar switches.Mellanox's InfiniBand host bus adapters and network switches, forexample, are used in many commercially available computer systems anddatabases.

The following terms may be construed either in accordance with anyappropriate definition thereof appearing in literature in the relevantfield of technology, or in accordance with the specification, or toinclude in their respective scopes, the following:

The term “Fabric” is intended to include, by way of non-limitingexample, the fabric illustrated at the following https link:etherealmind.com/wp-content/uploads/2011/07/what-switch-fabric-pt2-6.jpg/.

The term “privilege” refers to an individual attribute (e.g., of acomputer process) that allows a “privileged” process to perform asecurity-related operation (such as a memory access operation e.g.,access of a DPU to host memory from the ARM side) and does not allowother (“non-privileged”) processes to perform the same operation. Aprocess that is running with a privilege or privileges is called aprivileged process and the program that the process is running is calleda privileged or trusted program. A privileged computer process isauthorized and/or trusted, to perform at least one givensecurity-relevant function that other, (“non-privileged”) processes arenot trusted to perform, hence are not authorized to perform.

Host: a networked computer, such as, by way of non-limiting example, aDPU.

The terms “compute host” and “storage host” are defined in the followinghttps www online location: nvidia.com/en-us/networking/multi-host/.

A “key identifier” is an identifier e.g., a number or other string whichidentifies (is associated, typically uniquely, with) a given memoryregion and serves as a key (e.g., the key identifier must be given tothe hardware in order to access the given memory region).

“Memory isolation” occurs when a process A cannot access process B'smemory (e.g., cannot access any memory which is associated with anyprocess other than process A itself), except when process A is given theprivilege to access, or is granted explicit permission to access, tomemory associated with some process other than process A itself. Forexample, “logical” memory isolation may be achieved by an NTB whichprovides processor domain partitioning and address translation betweenmemory-mapped spaces of processor domains, such that devices on eachside of the bridge are not visible from the other side, and,nonetheless, data transfer and status exchange between the processordomains is possible.

The term “process” is intended to include, e.g., as described in thislink: en.wikipedia.org/wiki/Process_(computing), an instance of acomputer program that is being executed by one or many threads. Theprocess typically contains program code and its activity. Depending onthe operating system (OS), a process may include plural threads ofexecution, all executing instructions concurrently.

Bridge chip: a device that connects one bus (e.g., PCIe bus), on whichthere may be a first host, to another (e.g., PCIe) bus, on which theremay be a second host. A bridge chip may have on-board read and writequeues, may have prefetching functionality, and may have cachingfunctionality, either or both of which may be configurable by a user.

Local/remote: given a computer process performed by a first host, whichseeks access, via a bridge chip, to at least one local memory bufferresiding on a second host, a “local” key is a key from the first host,whereas a “remote” key is a key from the second host.

Read operation: includes reading data from remote host memory, andwriting that data to a local host's memory.

Write operation: includes reading data from the local host memory, andwriting that data to the remote host's memory.

“Offset” of a host is a term which defines where a memory transactionstarts in a given memory area or region pointed to by a given key. Forexample, especially when the memory area comprises a very large memoryregion, the offset (e.g., from the start of the region) and a lengthparameter may be used to define a sub region (within the given area)that a given transaction is to act on.

Register: intended to include storage, e.g., for a key identifier; ifthis occurs in accordance with the PCIe specification, each registercomprises a valid address on the device address space range or configspace, from which a host may read and/or from which a host may write.

An NTB (Non-Transparent Bridge) is a bridge chip which (e.g., asdescribed in the following online https www link:kernel.org/doc/html/latest/driver-api/ntb.html), connects plural memorysystems or memories residing on plural computers respectively, to asingle fabric (e.g., to a PCI-Express (aka PCIe) fabric in which casethe NTB may be termed a PCIe NTB chip). NTB hardware may supportread-and-writable registers that are accessible from both sides of thedevice, which allows peers to exchange a certain amount of data at afixed address. NTB client drivers register with the NTB core driver;registration may use the Linux Device framework, for example. NTB isuseful when it is desired to share some memory between plural systemswhich are deployed on the 2 “sides” of the bridge respectively.Typically, the NTB has an API which supports two types of memory windowinterfaces—inbound translation and outbound translation. The former istypically configured on a local NTB port, and the latter (outboundtranslation) is typically configured by the peer or remote side of thebridge, on the peer NTB port.

It may be useful, for a user of a multi-host environment, andspecifically in an environment which includes a SmartNIC or a DPU, tooffload some of the processing and computation to the DPU host itself(e.g., ARM cores on Bluefield®2). However, those offloaded processes mayneed access to data which resides on the main host itself (e.g., thex86). The problem to be addressed is how multiple processes in the DPUhost access asynchronously to different part of the memory of the mainhost with varying granularity or different granularities, while givingeach process different permission access, and ensuring that memoryisolation (e.g., as defined above) is provided between the variousprocesses. It is appreciated that if plural processes are to bedownloaded to a DPU host, each such process may need access to the hostmemory.

Possible solutions to the problem of how to support asynchronous accessof multiple processes in a host, to various portions of a main host'smemory having various granularities, include:

1. Legacy NTB—conventional APIs of conventional NTBs may include fixedmapping of the host memory to the NTB address space. Here, accessingdifferent portions or regions of memory typically involves reconfiguringthe window each time—which can only be done by a privileged process.Moreover, according to the PCIe specification, reconfiguring the windowtypically cannot be done asynchronously. If it is desired or needed tosupport accessing to different address spaces, a window for each addressspace may be required—which would likely translate to an unattainablesize of BAR.

2. RDMA—using RDMA read and RDMA write, one can overcome the problem.However, this solution requires an RDMA capable device and openingmultiple connections between each offloaded process to the host. It isappreciated that when an RDMA capable device opens plural connectionsbetween plural offloaded processes and a host, this undesirably consumesnetwork resources.

3. A client-server model of an RPC (remote procedure call) may be used.This involves the DPU host having a client daemon to send transactionsto read/write a memory on the main host and having an exposed API to theother process. The main host itself may have a server daemon to acceptthose transactions, execute them, and send a response, if and as needed.This solution requires additional utilization of the CPU—for both theDPU host and the main host. Moreover, this solution has high latencyoverall, and the required software is complex.

However, in contrast, certain embodiments of the invention include anNTB device API or IO API e.g., as shown in FIG. 1 which, typically,asynchronously supports both read and write, typically provides memoryisolation, and typically provides privileges for memory access.

Generally, the term “asynchronous” is used to differentiate from“synchronous” operation of a system in which tasks or IO operations ortransactions are performed one at a time, and only when one iscompleted, the next task is unblocked such that it is necessary to waitfor a task to finish before moving to the next task. In asynchronousoperations, a next task can begin before a previous task finishes. Thus,with asynchronous programming, multiple requests may be dealt withsimultaneously, enabling many more tasks to be completed in a givenperiod of time, thereby to facilitate parallelism. For example, aconventional computer process typically needs to wait to get memory,since a conventional or legacy NTB typically uses conventional PCIetransactions which generate a response only after a certain time haselapsed; this is not the case for the embodiments herein which areasynchronous.

A-synchronicity of tasks e.g., of NTB IO operations (e.g., read andwrite transactions between two hosts which may be interconnected by anNTB) and asynchronous I/O are defined in the following on-line entry:en.wikipedia.org/wiki/Asynchronous_I/O.

Thus, FIG. 1 illustrates an API (Application Programming Interface)apparatus, which is operative in conjunction with a bridge chip, a firsthost, and a second host, and which provides plural processes in a hostwith asynchronous access to plural portions of the memory of anotherhost.

The apparatus of FIG. 1 typically provides non-privilegedNon-Transparent Bridge control and IO, whereby plural processes in ahost, e.g., DPU host, may asynchronously access various portions of amain host's memory, e.g., in accordance with the method of FIG. 2 .Typically, no privileged process is required to control the NTB, since,instead, pre-registration is provided, in which key identifiers ofmemory region/s may be registered, and thereafter, NTB control can beprovided by at least one (typically any) process which has, previously,registered a key identifier of a given memory region which is being used(accessed from the local host by another host via the NTB, for example)in a given transaction or IO session between the 2 hosts.

The first host is, in some embodiments, external to the API (ApplicationProgramming Interface) apparatus, but in other embodiments the firsthost could be comprised therein. Similarly, the second host is, in someembodiments, external to the API (Application Programming Interface)apparatus, but in other embodiments the second host could be comprisedtherein. The bridge chip is, in some embodiments, external to the API(Application Programming Interface) apparatus, but in other embodimentsthe bridge chip could be comprised therein.

The apparatus of FIG. 1 typically includes 2 APIs, on both sides of thebridge chip e.g., NTB; each API belongs to different address space sincethe first API belongs to host1's address space, and the second APIbelongs to the host2 address space. According to certain embodiments,the hosts are connected to busses on either side of the NTB, and, whenone of the host's CPU uses the API, that host can, typically, access theother host's memory, via the bridge chip e.g., NTB. The non-transparentbridge or NTB may have, but does not necessarily have, scratchpadregisters and/or doorbell registers and/or heartbeat messages. The NTBdevice API may be via PCIe or any other suitable standard for deviceconnectors, and the transactions between the 2 hosts may or may not bePCIe transactions.

The second host may comprise a DPU e.g., a Bluefield®2 DPU in which casethe second host includes ARM processors and the DPU host may also betermed “the ARM side” or “DPU side\host” of the bridge, as opposed tothe other side of the bridge, which may be termed the “x86 side”(assuming the first or main host includes a x86 processor, as most do),or “main host side”, of the bridge.

In FIG. 1 , dotted vs. dashed lines are used to differentiate betweencommands on the 2 sides of the bridge respectively. The NTB is typicallysymmetric in that each NTB API generates a READ/WRITE to both hosts.

It is appreciated that DPU's can gain non-privileged random accesses tohost memory from the ARM side in an asynchronous way, e.g., via RDMA.However, the API shown and described in FIG. 1 may be a less complexsolution; for example, creation of a valid RDMA connection for usage mayinclude various commands and/or data structures which need not beprovided when using the API shown and described herein.

FIG. 2 is a method, which may be performed by the system of FIG. 1 andwhich provides non-privileged Non-Transparent Bridge control and IO,whereby plural processes in a host, e.g., DPU host, may asynchronouslyaccess various portions of a main host's memory, with variousgranularities. It is appreciated that the flow is typically asynchronousbecause the NTB is responsible for performing all the transactions, incontrast to legacy NTB architectures in which the process itself (notthe bridge) performs read/write transactions.

The method of FIG. 2 may be performed each time a process on a firsthost, host1, seeks to access a memory of a process on a second host,host2. Alternatively, or in addition, processes on host 2 may seek toaccess a memory of a process on the second host.

FIG. 2 may include all or any suitable subset of the followingoperations or those shown in FIG. 2 , suitably ordered e.g., as shown oras follows:

Operation 210: host1 (or a process thereon) has a memory request to beissued to host2 memory (e.g., to write data of given size into host2memory, or to read data of given size from host2 memory). Typically,host1 comprises the DPU host shown in FIG. 1 , and host2 comprises themain host (e.g., x86) shown in FIG. 1 . However, this is not intended tobe limiting, since other alternatives are also possible. For example,the host2 may comprise the DPU host shown in FIG. 1 , and host1 maycomprises the main host. Host1 could be either a compute host or astorage host, and the same is true of host2.

Host1 may make any suitable use of the memory subject of host1's memoryrequest, if host1's memory request is granted. Example use-case: host1may be a DPU to which host2 offloaded some process, e.g., in order touse the DPU as an accelerator. However, as a result, the offloadedprocess may have to access host2 memory (e.g., a database which host2uses), thus in this use-case, host1 (e.g., the process offloadedthereto) may need access to host2 memory. Also, certain devices may beconnected to a DPU and may not be connected directly to a host such asBlueField®-2× SSDs. If host1's request is granted, this could thenenable the device to access the host memory and/or could enable the host(e.g., the main host) to access DPU device buffer/s. It is appreciatedthat the above are but examples of the many use-cases in which a DPU mayneed non-privileged random accesses to host memory from the ARM side,e.g., in an asynchronous way.

According to certain embodiments, each process has a command gateway atits disposal (one gateway per process) e.g., as described herein.

Assume that in Operation 210, a “process 1” on host1 seeks to issue thememory request to the memory of “process 2” on host2. Subsequently, thefollowing operations may follow:

Operation 220: process 1 on host1 registers its local memory buffer inthe NTB and gets its key identifier (typically using the NTB API of FIG.1 ).

Operation 230: process 2 on host2 registers its local memory buffer inthe NTB and gets its key identifier (typically using the NTB API of FIG.1 ).

Typically, host2 gives host 1 the host2 key identifier typically througha method which is external to the NTB API. Any suitable technology maybe employed for exchanging key identifiers, such as, by way ofnon-limiting example, via network connection (e.g., TCP), via a sharedfile from which both hosts can read and/or to which both hosts canwrite, or even by manual copying.

It is appreciated that if the memory buffer being used is alreadyregistered, Operation 220 is typically omitted. Also, if the memorybuffer being used is already registered, Operation 230 is typicallyomitted.

Operation 240: process 1 on host1 issues the secured NTB access command(which may include all or any suitable subset of: <host1_key, host2_key,host1_offset, host2_offset, size, read/write>). This command may,generally, include a local address where the NTB writes a read responsewhich is required at a target address, or takes write data from, and/ora remote address serving as a target address for the read response orfor the write data, and/or transaction size, and/or indicator bitstipulating whether the transaction is a read transaction or a writetransaction (typically using the NTB API of FIG. 1 ).

It is appreciated that operation 240 onward can be done multiple times(depending on the number of accesses host1 needs to perform).

Operation 250: The NTB gets a command to perform the transaction

Operation 260: The NTB checks if the keys are valid and have permissions

Operation 270: Determination of validity e.g., yes/no

Operation 280: Report error

Operation 290: Issue the transaction

Operation 300: Increment a command counter, or write a completion bitindicating that command has been completed, e.g., in local address whichmay be in host1's own local memory. The term “completion bit” isintended to include a bit whose value indicates whether or not a certaintransaction has issued and is completed. Since, when the bridge chipfinishes a transaction, a “completion” bit is flipped (e.g., if the bitis 0, the bridge chip writes 1, or if the bit is 1, the NTB writes 0),and at least one (typically any) process can determine whether or not atransaction has been completed by tracking the completion bit's value.However, it is appreciated that implementation via a command counter orcompletion bit are described herein merely by way of non-limitingexample. Alternatively, any other appropriate method to track when atransaction has finished or been completed, may be used.

Typically, the command counter is physically stored on an internalmemory of the NTB. The command counter may, logically, form part of theaddress space range indicated by the BAR of the NTB.

Operation 310: Done.

According to certain embodiments, each time a process in host1 wants toissue a memory request to a portion of host2's memory, the flow of FIG.2 is performed. If for example, the method of FIG. 2 is performed ntimes by n processes in host1, where the n processes each seek to issuea memory request to a respective portion of host2's memory, each of then processes typically gains asynchronous access to the correspondingportion of host2's memory.

Any suitable action may be taken or not taken, responsive to an errorhaving been reported in operation 280. Typically, whichsoever entitye.g., process in host1 commanded the NTB to perform the transaction, isthe entity which gets the error report. One action that may be taken, isfor the entity e.g., process in host1 to issue a command to perform avalid transaction, if an error has been reported indicating that acommand previously issued by that entity, was not valid. For example, ifthe length field of a command issued by the process is greater than thesize of the memory region—the NTB may fail the command, but no fatalerror state is entered; instead, the method, after operation 280,returns to operation 250, and the process which issued the failed orinvalid command may issue another command to use a valid transaction, inwhich case no error would be reported in operation 80, and thetransaction may issue (operation 290). “Fatal” error states, if any, maybe defined using any suitable criterion e.g., may be a result of aninternal NTB HW implementation. For example, the NTB HW implementationmay create scenarios of fatal errors.

It is appreciated that incrementation of a command counter or flipping acompletion bit are 2 possible methods, mentioned by way of non-limitingexample, for indicating to the process which issued the command, thatthe asynchronous transaction, subject of operation 280, has beencompleted.

According to certain embodiments, memory isolation is achieved, sinceonly a process A which has a given key identifier can access a givenmemory, whereas at least one (typically any) process which does not havethe given key identifier cannot access the given memory. Thus, the givenmemory is isolated from all processes A.

The NTB API may be characterized by a command structure which includesall or any suitable subset of the following command structurecomponents: <local key, remote key, local offset, remote offset,transaction size e.g., in bytes, and a binary read\write bit>. The localand/or remote keys typically each uniquely identify a memory addressrange or memory region which the NTB can access; this allows securityand/or isolation to be enforced. Typically, certain portions of eachmemory region or range e.g., the first few bytes (say, 4) of the memoryregion are reserved for NTB use, e.g., for provision of command gatewaysas described herein. The stored local/remote offset may indicate anoffset from the start of the memory space identified, typicallyuniquely, by the key. The read/write bit indicates whether a giventransaction is a read operation or a write operation.

The NTB API command/s may be written, by at least one process, to a“command gateway” assigned thereto, typically uniquely, i.e., thecommand gateway is typically assigned to a given process, and to noother process. The NTB may then start processing the command and a newcommand may be written to the gateway. Typically, each command gatewayhas a corresponding “command counter” which increments upon commandcompletion; the command gateway and its command counter typicallyrequire no more than a few bytes of storage.

Multi-Host Environment

The API of the NTB may include a command in the following format:

-   -   <local address, remote address, size, read\write>

“local address” is the space to which the bridge chip may write the readresponse or from which the bridge chip may take the write data; theremote address is also termed the “target” address in the host memory,and size is the size of the transaction in bytes and read\write is thetransaction type.

Each time a process seeks to issue a read from the host memory inaddress X for S bytes and seeks to store the result in the process'saddress Y—the process may issue the command: <Y, X, S, read>.

The command for write transaction may be analogous e.g., each time aprocess seeks to issue a write of S bytes to the host memory at addressX, and the S bytes are currently in the process's address Y—the processmay issue the command: <Y, X, S, write>. After issuing this command, theprocess does not need to wait, since the NTB will handle the commandasynchronously. The NTB typically notifies the process of commandcompletion by incrementing a command counter which corresponds to acommand gateway via which this command was issued, or by storing acompletion bit in a local address which may reside, say, in the firstbyte of the local address. The process may then proceed accordingly,e.g., the program may, depending on its own logic, take some actionand/or refrain from taking some action, responsive to being notified ofcommand completion. For example, if a process in a host on one side of abridge is configured to read data from another host on the other side ofthe bridge, the process may begin using the data only upon receipt ofnotification of command completion. In contrast, it is appreciated thata conventional computer process typically needs to wait to get memory,since a conventional NTB uses conventional PCIe transactions whichgenerate a response only after a certain time has elapsed; this is notthe case for the embodiments herein.

To allow multiple processes to access the NTB concurrently, each processmay be given at least one “command gateway”, where that process maywrite its commands. It is appreciated that plural command gateways maybe assigned to a single process, however, to ensure isolation, pluralprocesses typically are not assigned to a single command gateway.

Since each process's command gateway/s need be only a few bytes in size,e.g., as long as the length of the command itself, up to thousands ofprocesses may be supported at the “cost” of but a few KB of BAR whichmay be devoted to a command gateway.

The KB devoted to the command gateway may comprise a suitable memoryaddress space or memory region which may be pointed to by the BaseAddress Register (BAR) and which typically is but a few KBs in size,sufficient to include the addresses of the command gateway. The KBdevoted to the command gateway may be part of the device BAR addressspace (which may or may not be resizable), thus may simply be memoryaddresses the device exposes to hosts, and may not be connected to anyactual memory. The NTB may have an internal queue which monitors thecommands written to the gateway aka GW (or may monitor the commandsusing any other suitable method or data structure). The NTB typicallycannot distinguish between different processes, and, instead, simplyenables a process to use the NTB if and only if that process has theright key. Thus typically, the NTB need not know how many commands arein the gateway, nor which command belongs to which process.

It is appreciated that even a conventional NTB may be configured totransfer a transaction (e.g., read or write) between two hosts. Thecommand gateway provided in accordance with certain embodiments servesas an interface for commanding the NTB to transfer a transaction (reador write) between two hosts. Typically, key identifiers, e.g., asdescribed herein, indicate to the NTB which memory region to operate on,and/or the size of the data to be read/write, and/or a read/write bitindicates to the NTB which type of transaction to issue.

To support permissions and/or isolation, key identifiers may beemployed. The secured command format may, for example, include all orany suitable subset of the following format components:

<local key, remote key, local offset, remote offset, size, read/write>where local/remote key is an identifier, typically unique, for alocal/remote memory address range respectively, which the NTB canaccess, local/remote offset is the offset from the start of thelocal/remote memory space respectively, and the remaining parameters(size, read/write) characterize the transaction which the process seeksto issue by respectively indicating the amount of data to beread/written, and whether the transaction is a read-type or write-typetransaction.

Typically, the key identifier is required to be pre-registered by therelevant process with all relevant permissions, to ensure that only aprocess which owns a previously registered key identifier, uniquely(typically) identifying a given region in memory, may access the givenregion.

Typically, the keys are not one-time keys. A key identifier is typicallyregistered once, and may then, from that point onward, be usedrepeatedly by the NTB (e.g., unless and until unregistered explicitly).Thus, typically, even given a memory region which is to be used (readfrom and/or written to) multiple times using a given key, a singleregistration of that key identifier is sufficient, assuming indeed thatthe same key is used for all the various uses of the memory region. Anysuitable method may be used to register the memory such as, by way ofnon-limiting example, conventional memory registration methods known inInfiniBand technology e.g., as described in the following https wwwlink: rdmamojo.com/2012/09/07/ibv_reg_mr/.

It is appreciated that each process registers its key identifier, and,typically, such pre-registration occurs each time a memory region needsto be accessed by the NTB, because use of the NTB with the memory regiontypically requires that the memory region be registered, and that thekey identifier which, typically uniquely, identifies the registeredmemory region be provided as a condition for accessing that region. Theentity responsible for registering a specific memory region is typicallythe process which owns this memory region.

It is appreciated that in conventional use of NTB to share memorybetween 2 hosts, the NTB may create a region on its own address spacewhich points to the memory region of the host.

If Host A wants to write to Host B, then all or any suitable subset ofthe following operations may be performed:

Operation 1a: Host A may configure the NTB window to point to thedesired memory

Operation 1b: Host A may notify Host B that Host B may write

Operation 1c: Host B may write its actual data to the NTB address space.

The NTB may forward this write to the memory that the NTB window pointsto (to the Host A memory). Typically, this window allocation on the NTBaddress space limits the size and/or amount of memory which can bespanned using a single NTB. Alternatively, however, an NTB providedaccording to embodiments of the present invention, does not include theabove type of window—and instead copies from a region on Host A to aregion on Host B (or vice versa). For example (using the above example),if Host A wants to write to Host B, then all or any suitable subset ofthe following operations may be performed:

Operation 2a: Host A may register a memory region with write permission

Operation 2b: Host B may register a memory region with read permission

Operation 2c: Host A may notify Host B about the Host A key

Operation 2d: Host B may write its data to its registered region

Operation 2e: Host B may write a command which commands the NTB to copyfrom Host B memory pointed by Host B key to Host A memory pointed byHost A key.

Thus typically, Host B does not write the actual data because thecommand typically does not include the actual data. It is appreciatedthat, typically, Host B needs the Host A key to proceed, which preventsother processes on Host B from gaining access to memory. Typically, aNTB command is valid if and only if it includes both keys—a local keyand a remote key.

It is appreciated that embodiments herein have many advantages inpractice, such as, by way of non-limiting example, the following:processes in a first host accessing the other host memory may benon-privileged. Security and isolation between processes is maintained.Multiple processes are supported. Asynchronous access to host memory,typically with more than one level of granularity, is supported. It isappreciated that granularity may define a relationship e.g., a ratiobetween amounts of computation and of communication. If parallelism isfine-grained, task code sizes and execution times are small, and smallamounts of data (e.g., a few memory words or less) is communicatedbetween processors frequently. Conversely, if parallelism iscoarse-grained, task code sizes and execution times are large, and theamounts of data transferred among processors are also large and aretransferred among processors infrequently. Thus, granularity defines howfrequently data is communicated, and with which amount (large or small)of computation. It is appreciated that determination of granularitytypically is subject to the following tradeoff: fine granularityincreases parallelism and speed, but also increases overheads ofsynchronization and communication. Conversely, coarse granularitydecreases parallelism and speed, but also decreases overheads ofsynchronization and communication.

According to certain embodiments, use of the system of FIG. 1 and/or ofthe method of FIG. 2 allows multiple processes in a host, e.g., DPUhost, to asynchronously access different parts of a main host's memory,with various granularities.

Example 1: Consider a single offloaded process with a single granularitye.g., table entry size. This offloaded process may need to access a fewentries in a table in main host memory. The table size is huge (e.g.,tens of GB) whereas each entry therewithin is small (e.g., a few byteseach). The table cannot, due to its large size, be mapped all at oncethrough legacy NTB, so accessing to the first entry and to the lastwould require costly re-configuring of the legacy NTB. In contrast, theAPI described herein, e.g., via the embodiments of FIG. 1 and/or FIG. 2, allows this access to take place with just one registration (of justone local memory buffer in the NTB, for example).

It is appreciated that use of the embodiment of FIG. 2 in the aboveExample 1 typically reduces communication overhead and/or prevents loadimbalance, where load indicates the number of processes which use theNTB and how NTB resources are allocated to each.

Still with reference to Example 1, it is appreciated that on legacy NTB,each window reconfiguration requires notifying the other host. Thus,accessing an entry on the table which is not mapped requiresreconfiguring the window and letting the other host know about thewindow reconfiguration. In contrast, when using the API shown anddescribed herein (e.g., when using the embodiment of FIG. 2 ), theentire table is mapped all at once.

It is appreciated that load imbalance would result if, say, process Aonly requires accessing a few table entries, but maps the entire table.In this situation, only one mapping is required, and the mapping iscoarse since it includes considerable unused table entries/regions. Incontrast, if the window only includes the memory needed each time, thewindow typically needs to be configured on each access, thus each windowconfiguration typically requires communication to inform the other hostabout the window reconfiguration.

It is appreciated that references herein to memory regions may beinterchanged with references to buffers, and vice versa.

Example 2: The offloaded process needs to access big data residing onthe main host. If legacy NTB were to be used, the big data may all bemapped, however, using that big data would require the process totransfer or read this big data itself from the window, which wouldrequire the process to use its own resources for accessing the big data.In contrast, if the API described herein, e.g., as per the embodimentsof FIG. 1 and/or FIG. 2 , is employed, the NTB does the transactions andcopies the transaction results to whichever memory buffer wasregistered, thereby freeing the offloaded process's resources for othertasks. It is appreciated that embodiments herein improve parallelperformance, by enabling a better balance between load and communicationoverhead. Due to the fact that varying granularity is supported,performance is no longer strictly subject to the above tradeoff.Instead, according to certain embodiments, the eventuality of too finegranularity, in which performance suffers from communication overhead,may be reduced or eliminated, and the eventuality of too coarsegranularity, in which performance suffers from load imbalance, may alsobe reduced or eliminated.

It is appreciated that in Example 2, the CPU is used less (is used moreparsimoniously) since the copying is performed by the NTB, rather thanby the CPU.

DPU use-cases, for example, may require, or benefit from, or be improvedby, non-privileged random accesses to host memory from the ARM side,which are asynchronous.

FIGS. 3 a-3 b show examples of multi-host environments in whichembodiments herein may be implemented; as shown, each host is associatedwith a memory (aka MEM). The term “all” is used herein for simplicity,to describe example embodiments. It is appreciated however that,alternatively, whatever is said herein to be true of, or to characterizeor to pertain to, “all” members of, or “each” member of, or “every”member of, a certain set can also, in other embodiments, be true of, orcharacterize or pertain to, most but not all members of that set, or allbut a few members of that set, or at least one (but less than all)member/s of the set.

It is appreciated that software components of the present invention may,if desired, be implemented in ROM (read only memory) form. The softwarecomponents may, generally, be implemented in firmware or hardware, ifdesired, using conventional techniques. It is further appreciated thatthe software components may be instantiated, for example as a computerprogram product, or on a tangible medium. In some cases, it may bepossible to instantiate the software components as a signalinterpretable by an appropriate computer, although such an instantiationmay be excluded in certain embodiments of the present invention.

It is appreciated that various features of the invention which are, forclarity, described in the contexts of separate embodiments, may also beprovided in combination in a single embodiment. Conversely, variousfeatures of the invention which are, for brevity, described in thecontext of a single embodiment, may also be provided separately, or inany suitable sub-combination.

It will be appreciated by persons skilled in the art that the presentinvention is not limited by what has been particularly shown anddescribed hereinabove. Rather, the scope of the invention includes,inter alia, the appended claims and equivalents thereof.

The invention claimed is:
 1. An apparatus that implements an API(application programming interface) that is operative in conjunctionwith a bridge chip, a first host and a second host, wherein the firstand second hosts have first and second memories, respectively, andwherein the bridge chip connects the first and second memories, theapparatus comprising: a processor that provides: key identifierregistration functionality to register a key identifier for each ofplural computer processes performed by the first host, thereby to defineplural key identifiers; access control functionality to provide at leastone computer process P1 performed by the first host with access, via thebridge chip, to at least one local memory buffer M2 residing in thesecond memory after the access control functionality first validatesthat said at least one computer process P1 has a key identifier whichhas been registered via the key identifier registration functionality,and wherein the access control functionality also prevents at least onecomputer process P2, which is performed by the first host and which hasnot registered a key identifier via the key identifier registrationfunctionality, from accessing the at least one local memory buffer M2via the bridge chip, an additional key identifier registrationfunctionality; and an additional access control functionality, whichprovides at least one computer process P3 performed by the second hostwith access via the bridge chip to at least one local memory buffer M1residing in the first memory after the additional access controlfunctionality first validates that said at least one computer process P3has a key identifier which has been registered via the additional keyidentifier registration functionality, and wherein the additional accesscontrol functionality also prevents at least one computer process P4,which is performed by the second host and which has not registered a keyidentifier via the additional key identifier registration functionality,from accessing the at least one local memory buffer M1 via the bridgechip.
 2. The apparatus according to claim 1, wherein the first hostregisters said at least one local memory buffer M1 in the bridge chipand, responsively, receives a key identifier from the bridge chip. 3.The apparatus according to claim 1, wherein the second host registerssaid at least one local memory buffer M2 in the bridge chip and,responsively, receives a key identifier from the bridge chip.
 4. Theapparatus according to claim 1, wherein at least one command to performa read transaction is issued by the first host and wherein the at leastone command comprises a target address and a local address where thebridge chip writes a read response which is required at the targetaddress.
 5. The apparatus according to claim 4, wherein the at least onecommand also comprises a transaction size parameter indicative of anamount of data to be read.
 6. The apparatus according to claim 4,wherein the bridge chip receives said at least one command via the APIand makes a validation attempt including attempting to validate thatsaid at least one command has a valid key from said first host and avalid key from said second host and wherein the read transaction isperformed only after the bridge chip succeeds in said validationattempt.
 7. The apparatus according to claim 6, wherein an error messageis generated each time the bridge chip determines that the first hostdoes not have a key identifier registered via the key identifierregistration functionality.
 8. The apparatus according to claim 4, andwherein, to indicate that the read transaction has been performed, acommand counter is incremented.
 9. The apparatus according to claim 4,wherein a completion bit is provided to indicate that the readtransaction has been performed.
 10. The apparatus according to claim 1,wherein at least one command to perform a write transaction is issued bythe first host and wherein the at least one command comprises a targetaddress and a local address from which the bridge chip takes write data.11. The apparatus according to claim 10, wherein the at least onecommand also comprises a transaction size parameter indicative of anamount of data to be written.
 12. The apparatus according to claim 10,wherein the bridge chip receives said at least one command via the APIand, responsively, makes a validation attempt including attempting tovalidate that said at least one command has a valid key from said firsthost and a valid key from said second host, and wherein the writetransaction is performed only after the bridge chip succeeds in saidvalidation attempt.
 13. The apparatus according to claim 10, wherein, toindicate that the write transaction has been performed, a commandcounter is incremented.
 14. The apparatus according to claim 10, andwherein a completion bit is provided to indicate that the writetransaction has been performed.
 15. The apparatus according to claim 1,wherein the bridge chip comprises a Non-Transparent Bridge (NTB) whichconnects plural memories residing on plural computers, respectively, toa single PCI-Express fabric.
 16. The apparatus according to claim 1,wherein the second host includes a smart Network Interface Card (NIC).17. The apparatus according to claim 16, wherein the second hostcomprises a Data Processing Unit (DPU).
 18. The apparatus according toclaim 1, which provides an interface to the bridge chip and providesmemory isolation between at least one computer process A performed bythe first host and the at least one local memory buffer M2.
 19. Theapparatus according to claim 1, wherein the further comprising includesthe bridge chip, the first host, and the second host.
 20. The apparatusaccording to claim 1, wherein the key identifier identifies the at leastone local memory buffer M2.
 21. The apparatus according to claim 1,wherein the key identifier uniquely identifies the at least one localmemory buffer M2.
 22. An application programming interfacing (API)method operative in conjunction with a bridge chip, a first host and asecond host, wherein the first and second hosts have first and secondmemories, respectively, and wherein the bridge chip connects the firstand second memories, the method comprising: registering a key identifierfor each of plural computer processes performed by the first host,thereby to define plural key identifiers; providing at least onecomputer process P1 performed by the first host with access via thebridge chip to at least one local memory buffer M2 residing in thesecond memory after first validating that said at least one computerprocess P1 has a key identifier which has been registered; preventing atleast one computer process P2, which is performed by the first host andwhich has not registered a key identifier, from accessing the at leastone local memory buffer M2 via the bridge chip; providing at least onecomputer process P3 performed by the second host with access via thebridge chip to at least one local memory buffer M1 residing in the firstmemory after first validating that said at least one computer process P3has a key identifier which has been registered; and preventing at leastone computer process P4, which is performed by the second host and whichhas not registered a key identifier via the additional key identifierregistration functionality, from accessing the at least one local memorybuffer M1 via the bridge chip.